# 前言
本章将会介绍 CLI 的开发与一些相关的知识。
# CLI 工具分析
小团队里面的业务一般迭代比较快，能抽出来提供开发基建的时间与机会都比较少，为了避免后期的重复工作，在做基础建设之前，一定要做好规划，思考一下当前最欠缺的核心与未来可能需要用到的功能是什么？
Coding 永远不是最难的，最难的是不知道能使用 code 去做些什么有价值的事情。
本系列先简单规划出 CLI 的四个大模块，后续如果有需求变动再说。
可以根据自己项目的实际情况去设计 CLI 工具，本系列仅提供一个技术架构参考。
# 构建
通常在小团队中，构建流程都是在一套或者多套模板里面准备多环境配置文件，再使用 Webpack Or Rollup 之类的构建工具，通过 Shell 脚本或者其他操作去使用模板中预设的配置来构建项目，最后再进行部署之类的。
这的确是一个简单、通用的 CI/CD 流程，但问题来了，只要最后一步的发布配置不在可控之内，任意团队的开发成员都可以对发布的配置项做修改。
即使构建成功，也有可能会有一些不可预见的问题，比如 Webpack 的 mode 选择的是 dev 模式、没有对构建代码压缩混淆、没有注入一些全局统一方法等等，此时对生产环境而言是存在一定隐患的。
所以需要将构建配置、过程从项目模板中抽离出来，统一使用 CLI 来接管构建流程，不再读取项目中的配置，而通过 CLI 使用统一配置（每一类项目都可以自定义一套标准构建配置）进行构建。
避免出现业务开发同学因为修改了错误配置而导致的生产问题。
# 质量
与构建是一样的场景，业务开发的时候为了方便，很多时候一些通用的自动化测试以及一些常规的格式校验都会被忽略。比如每个人开发的习惯不同也会导致使用的 ESLINT 校验规则不同，会对 ESLINT 的配置做一些额外的修改，这也是不可控的一个点。一个团队还是使用同一套代码校验规则最好。
所以也可以将自动化测试、校验从项目中剥离，使用 CLI 接管，从而保证整个团队的某一类项目代码格式的统一性。
# 模板
至于模板，基本上目前出现的博客中，只要是关于 CLI 的，就必然会有模板功能。
因为这个一个对团队来说，快速、便捷初始化一个项目或者拉取代码片段是非常重要的，也是作为 CLI 工具来说产出最高、收益最明显的功能模块，但本章就不做过多的介绍，放在后面模板的博文统一写。
# 工具合集
既然是工具合集，那么可以放一些通用的工具类在里面，比如
- 图片压缩（png 压缩的更小的那种）、上传 CDN 等
- 项目升级（比如通用配置更新了，CLI 提供一键升级模板的功能）
- 项目部署、发布 npm 包等操作。
- 等等其他一些重复性的操作，也都可以放在工具合集里面
# CLI 开发
前面介绍了 CLI 的几个模块功能设计，接下来可以正式进入开发对应的 CLI 工具的环节。
# 搭建基础架构
CLI 工具开发将使用 TS 作为开发语言，如果此时还没有接触过 TS 的同学，刚好可以借此项目来熟悉一下 TS 的开发模式。
mkdir cli && cd cli // 创建仓库目录
npm init // 初始化 package.json
npm install -g typescript // 安装全局 TypeScript
tsc --init // 初始化 tsconfig.json
全局安装完 TypeScript 之后，初始化 tsconfig.json 之后再进行修改配置，添加编译的文件夹与输出目录。
{
"compilerOptions": {
"target": "es5", /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', 'ES2018', 'ES2019', 'ES2020', 'ES2021', or 'ESNEXT'. */
"module": "commonjs", /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', 'es2020', or 'ESNext'. */
"outDir": "./lib", /* Redirect output structure to the directory. */
"strict": true, /* Enable all strict type-checking options. */
"esModuleInterop": true
